BACKGROUND 


BUILDING 


DATABASE 


e= JUN 


In this final installment of our series, Wilf Hey reviews S YS TEMS 


the basic process of database design, and discusses 
functions within the SR-Info database software. 


GLOSSARY 
DATABASE SYSTEM - The software 
that provides the tools for creating, 
accessing, and maintaining database 
files; often the database system 
includes a program interpreter, so 
that it (rather than the operating 
system) is actually responsible for 
running the database programs. 


DATABASE FILE - A collection of 
individual records, all of the same 
general format. In SR-Info a database 
file has the extension .DBF. 


DATABASES 


RELATIONAL DATABASE - A database 
system that makes it easy (or 
automatic) to use keys for linking 
related records from two or more 
database files. 


FIELD - A unit of data assigned a 
name, and defined in terms of its size 
and type. Fields are grouped 
together to form the structure of a 
database file. 


SIZE - The length of a field - the 
same (for that field) in every record 
in the database file, even when the 
field is empty. 


STRUCTURE - The definition of what 
information is held within a database 
file; this is made up of fields. Each 
record in a particular database file 
has the same structure. 


KEY -A field (or group of fields) that 
occurs in each record of a database 
file, used to make records easy to 
locate, or easy to group together. A 
key can also be used to put the 
records of a database file into a 
specific order for printing. 


INDEX - A tiny file related to a key, 
used by the database system to pick 
records out of a database file. In 
SR-Info, index files have the 
extension name .NDX. 
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atabase applications are the most 
D common use of computers. A 

database system can be used for 
many jobs — from a government’s 
statistical records stored on mainframe 
computers, to collecting favourite 
recipes on a home PC. 

This series has given you the 
opportunity and the guidance necessary 
to build your own database, learning and 
applying the skills common to all 
database applications. 

The dominant basic idea behind all 
database applications is the need for 
storing data in an organised way, so that 
information can be added to, adjusted, 


and consulted with maximum ease. 

You need to develop two skills to 
make a working database; first, the 
design of database structures; second, 
writing the programs that enable you to 
use and maintain the database. 

This series has been built in two 
parts, discussing these skills separately. 
In Designing a Database we have been 
looking at the design principles that 
apply to all database systems — whatever 
database package or language is used. In 
Developing with SR-Info we have looked 
at how those principles work in practice, 
using the SR-/nfo database language 
(from the March 1991 SuperDisk). 


DEVELOPING WITHSR-INFO = 


To work through our practical using the 
SR-Info database package, you should 
make sure you are up-to-date with 
changes that we made last month on our 
Magazine Articles project. 

We found that the program we 
created to list articles recorded in the 
database needed modification to be 


Here’s our solution: oe 
DO WHILE AUTHOR-FINDER as: NOT. BOF() 
@ 10,18 SAY AUTHOR ~ ey 

@ 11,10 SAY BLANK(31) 

@ 14,10 SAY BLANK(27) 

@ 11,10 SAY TRIM(FULLNAMEH2) + " 
@ 12,10 say Sigal Bie ra 


flexible enough to use all three different 


key sequences; instead of our original 
plan (a subprogram called LISTITEM) - 
we have decided to make a major — but 


easy — modification. Now we have three 
versions of the subprogram (one for each 


key sequence) instead of the one. 
Last month we were left with one | 
major bug — it sits in the subprograms 
LISTITEA (authors sequence), 
LISTITES (subject sequence) and 
LISTITET (title sequence). There are 
also a few more limitations to amend. 


The bug is quite ns nent AUT 


select AUTHOR sequence, press [W], 
then [Enter] when asked for an author, 
_ and see what the database does. It 


displays details of an article, but whois _ 


the author? Apparently, his name is ‘W’. _displaye 
Tas arp ies 1) all ais play area te Ww. 


‘thatfollow. 
How a you attack this is problem? 


DESIGNING A 
4 DATABASE 


. A database system can be as simple as a 

4 single file — you can write a company 
name, address and telephone number on 

. an index card, and keep a collection of 

them in a box, sorted by name into 

2 alphabetical order. 

4 If you are keeping more information 
than that — type of business, main 
product, and so on — each card will 


|! contain a lot of information, yet there 
will be no easy way to access all the 
a facts. For example, only a long search 


can tell you the names of the companies 
specialising in electrical connections. 

A useful computer database will 
usually be made up of several files, 
rather than one. For instance, a video 
rental library will want to keep track of 
which tapes are borrowed by which 
members — this amounts to matching up 

”“ two or more sets of things (tapes and 
members) in different ways. 

Many jobs boil down to the same 
thing — matching passengers to flights 


SPOOL RUBBISH. BAK 
EJECT 
SPOOL 


| can be cleared off your disk at any time. 


STARTING A LISTING WITHOUT 


WASTING PAPER 


A little tip, if you want to make sure your ‘@ SAY’ numbering is aligned before 
you print, but don’t want to waste a page by throwing to top-of-form with the 
EJECT command; look at these three lines, and see what they do 


| It doesn’t matter whether you have SET PRINT ON or not, because EJECT will 
always go to the printer - or to a spooled file. This bit of code makes sure that 
you don’t lose that blank page. True, it creates a small file, but it is one that 


(in an airline’s system), customers to 
items purchased (in any invoicing 
system), students to classes, or 
companies to products. On the 
SuperDisk we’ve been developing a 
database of magazine articles, which 
relates magazines, authors, and topics. 


STRUCTURE IN A NUTSHELL 

In addition to being accessible, a 
database must be compact and 
manageable. As we have seen over the 
last few months, there are several things 
you can do to organise how information 
is kept in a database with exactly that 
goal in mind. 

You can design and organise your 
database in three main steps — ‘gather’, 
‘group’, and ‘refine’. 

Let's carefully review these steps, 
using our Magazine Articles database as 
an example. 


FIRST STEP —- GATHER 

Our first step is to gather together all the 
information that may prove relevant. We 
aren’t gathering the actual data about the 


magazine articles, instead we’re thinking 
of the sorts of things we want to record. 

The magazine database application 
doesn’t just have article titles and 
magazine names; it has authors, issue 
numbers, page numbers, and topics. 
Along with each magazine’s name there 
is its cover price and its editor’s name. 
Some of this information is obviously 
necessary. Some may seem unnecessary 
— until you think of what uses could be 
made of the database. 

It’s probably a good idea at the outset 
to include the magazine’s address — we 
may want to write to the editor, and it 
would be useful to have this information 
ready to be fed into a word processor. 
Even if we don’t intend to use all this 
data immediately, it can’t do much harm 
to anticipate future needs. 

As we have seen, we should assign 
short names for each of these sorts of 
information, decide on their size and 
their ‘type’ — text for names, addresses, 
and similar information, figures for 
quantities. (Some database languages 
have other types — dates, logical, and so 
on). The assigned name, size and type is 
then called a ‘field’ within the structure 
— but we’re not finished there. 


SECOND STEP — GROUP 
Our next step is to group the different 
types of information in sensible ways; 
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each group of fields will form the basic 
structure of a database file (remember 
that there may well be more than one file 
in the database). 

The cover price, address and editor’s 
name really have more to do with the 
magazine than they do with an individual 
article. It’s quite likely that this 
information will be repeated for many 
different articles. Therefore, rather than 
repeat the information over and over 
again, it would be much better to group 
the magazine-related fields together into 
a different file altogether. 

When you think of how the database 
will eventually work, you can start to see 
the advantage of having two separate 
files — one with a structure made up of 
article-related fields, and one consisting 
of magazine-related fields. This 
system keeps all the information in a 


It is quite easy to create a little 
program that confirms the value of 
keys, as understood by the INKEY 
function. Why not code one as an 
exercise? If you find that you can’t 
work it out, study this for ideas: 


* Here is where we define the window 


DATABASES 


RO = 5 
co = 33 


HERRERA RARE RK 


WINDOW RO,CO,RO+6,CO+40 
@ RO+1,CO say cen("INKEY utility", 40) 
@ RO+3,CO say cen("Press any key",40) 
esctoend="ESC to end" 


RRR RR RR RE 
DO WHILE .t. 


RING 
ENDDO 
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BUILDING AN ‘INKEY’ UTILITY 


* set RO to desired row, CO to desired column 


@ RO+7,CO+20-len(esctoend)/2 say esctoend 


@ RO+5,CO say cen("That key has a value of "+str(inkey(),3),40) 


much more compact way. 

It also makes changing things a great 
deal easier; if a magazine moves its 
office, it makes sense to change the 
information in just one place, rather than 
in the record of every single article that 
has appeared in the magazine. 

Of course, there must be provision 
for some way to link records between the 
two files; otherwise you couldn’t (for 
example) write to the editor about a 
particular article — the TITLE field is 
found in the articles file structure, but the 
necessary EDITOR field is in the 
magazine file structure. 

We could make a third file — each 
record holding details of the authors 
from whom those articles come. Creating 
the structure for his file can make the 
whole database more compact; the 
author’s qualifications, for instance, need 


@ This little utility allows 
the database programmer 
to test values returned by 

the INKEY function; he can 
actually use this to build in 
tests for control keys into 
database programs. 


only exist once (on a single record of an 
AUTHORS database file) rather than 
many times (on several records in the 
ARTICLES database file). 


THIRD STEP — REFINE 

Now we must refine the structures of the 
files in the database. As we have seen, 
there is a powerful way to avoid needless 
repetition of data — we simply invent a 
new file and establish a link to its 
records; then any number of article 
records within the database can use the 
same data, treating it as a record of that 
new file. 

A single record in the ARTICLES file 
will be related to a single record in the 
MAGFILE database, for example. The 
one piece of information that is common 
to both these two files is the name of the 
magazine. This particular bit of 
information must appear as a field in 
both files — that is in ARTICLES as a 
‘linking field’ and in MAGFILE as a 
“key field’. Simply knowing the 
magazine’s name gives you an instant 
pointer to all sorts of other information 
about the magazine — from the specific 
record in MAGFILE. 


FINE TUNING 

There are still further refinements that 
can reduce the size of the database. Here 
are a few suggestions: 

Firstly, we can reduce the size of our 


om 
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DATABASES 


linking fields and keys — perhaps by 
using a nickname, or a number. 
Surprisingly, this can even be a help 
with a fairly small group, such as the 
choice among ten magazines whose 
articles you collect. 

If the linking field between an article 
record, and a magazine record is three 
characters long instead of twenty-five, 
you will be saving twenty-two precious 
bytes per article record — of which there 
will not be just ten, but potentially 
hundreds or thousands. 

This shortened field is known as an 
‘artificial’ key — you may wish to use it 
for internal purposes only, but don’t 
dismiss the possibility of making this 
key official. Bank account numbers, for 
example, are actually artificial keys. (It’s 
important to remember that by ‘artificial’ 
we mean made up — we do not 
necessarily mean fictitious). 

We can also invent nicknames for 
fields that have a limited, repeated range 
of values. For example, the 
FREQUENCY field within the 
MAGFILE database could easily be 
abbreviated to W for weekly, M for 
monthly, Q for quarterly, and so on. 

This nickname can then be used as a 
linking field into a database which only 
has its key, plus the expanded meaning 
(for example — the key ‘Q’, with the 
expanded meaning of ‘Quarterly’). 
Don’t be afraid to create such a tiny 
database — it can save you space, and 


_ coded, and so all ‘@ SAY’ commands 
_ send output to the screen. You can 
change this simply by sending the 
command, SET PRINT ON. 
You should also note how to force a 
__ new page on the printer — the command 


_ EJECT will do the job, but don’t try it if 
you are going to the screen. 


_ You can even ‘print’ when your 
_ printer is not available simply by using 


the SPOOL command. SPOOL 


_ MYFILE, for example, will open a disk 

file called MYFILE.TXT — and if we 

_ SET PRINT ON, the output will go 
neither to the screen, nor the printer, but 


_ to MYFILE.TXT (you stop this with 


_ SPOOL — no parameter). You can even 
_ print MYFILE.TXT subsequently — 

__ when the printer is available, by 

_ executing the command SPOOL 


- MYFILE.TXT TO 1 (the number is the 


a printer port being used). 


_ UPDATING INFORMATION 


__ Modifying database information safely is 
essential. There are few file commands 
within SR-Info; this is intentional — so 


that individual commands are less likely 
to corrupt the relationships set up so 
carefully. We have seen GO TOP, GO 
BOTTOM and SKIP — all commands 
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still give you the same full information 
without extra effort. 


MORE KEY INFORMATION 

When used to link files together, the 
linking field (in one file) and its 
matching key (in the other file) serve the 
same purpose as a pencilled note on the 
bottom of an index card such as ‘refer to 
card 432 in the PRODUCTS cardfile’. 

A key can also be used to find 
particular records within one database 
file. If you have a PUBLISHER field on 
your magazine file and designate that as 
a key, you could have a simple program 
search for all ‘Future Publishing’ titles, 
and find among them not only PC PLUS, 
but also AMIGA Format, 8000 PLUS 
and others. 

The third use of keys makes it easy to 
produce reports in any particular order. 
If you wish to print a list of articles 
grouped together in topic sequence, the 
report program needs only to read the 
articles database using the TOPIC index 
—a tiny file of pointers to the articles, 
sorted into good order by using TOPIC 
as a key-field. 

We saw that a key field — for file- 
linking purposes — should have a unique 
value, but with these two new uses, there 
is no such restriction. When finding 
records (as in ‘on line enquiry’) or 
grouping records (for reports) we can 
cope quite easily with the same value 
appearing in the key field of two or more 


that position you to a new place within 
the database. If you know the number 
(that is, position within the database) of a 
particular record, you can specify this 
with the GO command, but it is rare that 
this is useful. Perhaps it can be used to 
resume at a certain place, after being 
interrupted for some other operation. 

There is no ‘rewrite’ command — but 
records can be modified with a special 
kind of ‘move’ command. As we have 
seen, memory variables can be modified 
by resetting their value with an equal- 
sign operation; examples are: 


COUNTER = COUNTER + 1 
NEWMESSAGE = "NO PROBLEMS" 


You can do the same with database fields 
on the left-hand side of these 
expressions, but you only change the 
record temporarily, while it is in the 
computer’s memory — it doesn’t get 


changed on the disk. However, let’s 


suppose COUNTER and 
NEWMESSAGE are actually database 


- fields. We can make the change 


permanent by coding: 


REPLACE COUNTER WITH COUNTER + 1 


_ REPLACE NEWMESSAGE WITH "NO PROBLEMS” 


records. Be careful, sometimes a key 
will be used for more than one of these 
three ways. And do not forget —a 
database file can have more than just the 
one key (although only one key can be 
‘used’ at a time). 

One further thing to note about keys; 
though we have spoken of a key as being 
a field, it can actually be a group of 
fields — in some systems (including SR- 
Info), those fields don’t even have to be 
next to each other in the record structure. 


AND FINALLY... 

This brings our general introduction to 
database design to a conclusion. In the 
last four months we have looked at all 
the basic principles used when designing 
a database structure, but there are many 
specialised subjects that deserve 
discussion in depth at a later time. For 
example, the use of a database file — how 
rapidly its contents change — has a 
bearing on efficient design. From time to 
time in future issues we will look at 
these subjects. 

Armed with these introductory 
studies, you will now have the means to 
design working database systems. We 
are interested in your ideas, suggestions, 
and results — please send us your work. 
The best SR-Jnfo examples — whether 
modifications to the skeletal 
MAGAZINE ARTICLES database, or 
entirely new applications — will appear 
on future SuperDisks. @ 


We use REPLACE not only to change _ 
existing records in the database, but also. 
for adding records as well. You see, the 
most secure way of adding anew record 
to the database is to use a simple 7 
command, APPEND BLANK. This adds _ 
a record to the active database (the one 
pointed to by the last SELECT), points 

to it, and you are now ready to 

REPLACE its fields. 


ALTERNATIVES 


‘There is one other way to make > 


permanent changes to the active 

database, but many programmers shun 
this method. The ‘@ GET’ operation 
also makes permanent changes, like the 
REPLACE command. It is more oe 
common to pick up keyed values with 
‘@ GET’, but place them into memory — 
(and therefore temporary) variables first, 
and REPLACE the database fields with 
the memory variables at a later stage. 
Remember that all the ‘@ GET’ : 
operations are put into action one-by-one 
when the READ command is executed — 
but things may ‘go wrong’ during the 
keying, and you may wishtostopany = 
updating that was started. Yet if you did 

a ‘@ GET’ intoa emcee = earlier, 


_ it’s too late. 


or 


